Skip to main content
Expert Talk
Amakomaya — Aamako Maya Apps Pvt. Ltd.

OpenMRS

OpenMRS is an open-source electronic medical record (EMR) platform built for low-resource settings. Like DHIS2 it is a platform rather than a finished product: a core data model plus modules, configured into a working clinical system.

The data model​

OpenMRS is built around a small number of ideas that repay understanding:

EntityMeaning
PatientA person receiving care, with one or more identifiers
VisitA period of contact with the health facility
EncounterA single clinical interaction within a visit
Observation (obs)One recorded fact, tied to a concept
ConceptThe definition of what can be recorded
OrderA request — drug, laboratory test, referral

The concept dictionary​

Almost everything recorded is an observation whose meaning comes from a concept. The concept dictionary is therefore the heart of an OpenMRS implementation: get it wrong and every downstream report inherits the problem.

Concepts have datatypes (numeric, coded, text, date), answers for coded concepts, and mappings to external terminologies — SNOMED CT, LOINC, ICD. Those mappings are what make an OpenMRS instance interoperable rather than a private vocabulary. The Open Concept Lab (OCL) is commonly used to manage dictionaries across systems.

Architecture​

  • Core — data model, API, service layer
  • Modules — clinical and administrative functionality, versioned separately
  • Frontend — the O3 microfrontend UI, or earlier reference application UIs
  • REST and FHIR APIs — the FHIR module exposes OpenMRS data as FHIR resources, which is the recommended integration path

Distributions bundle a curated set of modules and configuration for a use case (HIV care, primary care, hospital) — Bahmni is a well-known one, adding billing, laboratory and imaging integration.

Where it fits​

In an OpenHIE-style architecture OpenMRS is a point-of-service system: it produces clinical data and consumes registry data. It is not the national reporting system — aggregate reporting typically goes to DHIS2, and identity resolution belongs to the client registry.

Implementation notes​

  • Start from a distribution rather than assembling modules from scratch.
  • Design the concept dictionary with clinicians, and map to standard terminologies from the beginning; retrofitting mappings is expensive.
  • Plan for offline and intermittent connectivity — it is the norm, not an edge case.
  • Version modules deliberately. Module compatibility is the most common source of upgrade pain.
  • Decide the reporting path early — how clinical data becomes aggregate indicators.

References​

Last updated on